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Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes 


Abstract 


This document describes a QoS-NSLP Quality-of-Service model (QOSM) 
based on ITU-T Recommendation Y.1541 Network QoS Classes and related 
guidance on signaling. Y.1541 specifies 8 classes of Network 
Performance objectives, and the Y.1541-QOSM extensions include 
additional QSPEC parameters and QOSM processing guidelines. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 
evaluation. 

This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering 
Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


any level of 


all documents approved by the IESG are a candidate for 
Internet Standard; see Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5976. 
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carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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Les 


1. 


Introduction 


This document describes a QoS model (QOSM) for Next Steps in 
Signaling (NSIS) QoS signaling layer protocol (QoS-NSLP) application 
based on ITU-T Recommendation Y.1541 Network QoS Classes and related 
guidance on signaling. [Y.1541] currently specifies 8 classes of 
Network Performance objectives, and the Y.1541-QOSM extensions 
include additional QSPEC [RFC5975] parameters and QOSM processing 
guidelines. The extensions are based on standardization work in the 
ITU-T on QoS signaling requirements ([Y.1541] and [E.361]), and 
guidance in [TRQ-QoS-SIG]. 


[RFC5974] defines message types and control information for the QoS- 
NSLP that are generic to all QOSMs. A QOSM is a defined mechanism 
for achieving QoS as a whole. The specification of a QOSM includes a 
description of its QSPEC parameter information, as well as how that 
information should be treated or interpreted in the network. The 
QSPEC [RFC5975] contains a set of parameters and values describing 
the requested resources. It is opaque to the QoS-NSLP and similar in 
purpose to the TSpec, RSpec, and AdSpec specified in [RFC2205] and 
[RFC2210]. A QOSM provides a specific set of parameters to be 
carried in the QSPEC object. At each QoS NSIS Entity (QNE), the 
QSPEC contents are interpreted by the resource management function 
(RMF) for purposes of policy control and traffic control, including 
admission control and configuration of the scheduler. 


1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Summary of ITU-T Recommendations Y.1541 and Signaling Requirements 


As stated above, [Y.1541] is a specification of standardized QoS 
classes for IP networks (a summary of these classes is given below). 
Section 7 of [TRQ-QoS-SIG] describes the signaling features needed to 
achieve end-to-end QoS in IP networks, with Y.1541 QoS classes as a 
basis. [Y.1541] recommends a flexible allocation of the end-to-end 
performance objectives (e.g., delay) across networks, rather than a 
fixed per-network allocation.  NSIS protocols already address most of 
the requirements; this document identifies additional QSPEC 
parameters and processing requirements needed to support the Y.1541 
QOSM. 
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2.1. Description of Y.1541 Classes 


[Y.1541] proposes grouping services into QoS classes defined 
according to the desired QoS performance objectives. These QoS 
classes support a wide range of user applications. The classes group 
objectives for one-way IP packet delay, IP packet delay variation, IP 
packet loss ratio, etc., where the parameters themselves are defined 
in [Y.1540]. 


Note that [Y.1541] is maintained by the ITU-T and subject to 
occasional updates and revisions. The material in this section is 
provided for information and to make this document easier to read. 

In the event of any discrepancies, the normative definitions found in 
[Y.1541] take precedence. 


Classes 0 and 1 might be implemented using the Diffserv Expedited 
Forwarding (EF) Per-Hop Behavior (PHB), and they support interactive 
real-time applications [RFC3246]. Classes 2, 3, and 4 might be 
implemented using the Diffserv Assured Forwarding (AFxy) PHB Group, 
and they support data transfer applications with various degrees of 
interactivity [RFC2597]. Class 5 generally corresponds to the 
Diffserv Default PHB, and it has all the QoS parameters unspecified 
consistent with a best-effort service[RFC2474]. Classes 6 and 7 
provide support for extremely loss-sensitive user applications, such 
as high-quality digital television, Time Division Multiplexing (TDM) 
circuit emulation, and high-capacity file transfers using TCP. These 
classes are intended to serve as a basis for agreements between end- 
users and service providers, and between service providers. They 
support a wide range of user applications including point-to-point 
telephony, data transfer, multimedia conferencing, and others. The 
limited number of classes supports the requirement for feasible 
implementation, particularly with respect to scale in global 
networks. 


The QoS classes apply to a packet flow, where [Y.1541] defines a 
packet flow as the traffic associated with a given connection or 
connectionless stream having the same source host, destination host, 
class of service, and session identification. The characteristics of 
each Y.1541 QoS class are summarized here: 


Class 0: 

Real-time, highly interactive applications, sensitive to jitter. 
Mean delay <= 100 ms, delay variation <= 50 ms, and loss ratio <= 
10^-3. Application examples include VoIP and video teleconference. 
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Class 1: 

Real-time, interactive applications, sensitive to jitter. Mean delay 
<= 400 ms, delay variation <= 50 ms, and loss ratio <= 10^-3. 
Application examples include VoIP and video teleconference. 


Class 2% 

Highly interactive transaction data. Mean delay <= 100 ms, delay 
variation is unspecified, loss ratio <= 10^-3. Application examples 
include signaling. 


Class 3: 

Interactive transaction data. Mean delay <= 400 ms, delay variation 
is unspecified, loss ratio <= 10^-3. Application examples include 
signaling. 


Class 4: 

Low Loss Only applications. Mean delay <= 1 s, delay variation is 
unspecified, loss ratio <= 10^-3. Application examples include short 
transactions, bulk data, and video streaming. 


Class 5: 

Unspecified applications with unspecified mean delay, delay 
variation, and loss ratio. Application examples include traditional 
applications of default IP networks. 


Class 6: 

Applications that are highly sensitive to loss. Mean delay «- 100 

ms, delay variation <= 50 ms, and loss ratio <= 10^-5. Application 
examples include television transport, high-capacity TCP transfers, 
and Time-Division Multiplexing (TDM) circuit emulation. 


Class 7: 

Applications that are highly sensitive to loss. Mean delay <= 400 

ms, delay variation «- 50 ms, and loss ratio «- 10^-5. Application 
examples include television transport, high-capacity TCP transfers, 
and TDM circuit emulation. 


These classes enable service level agreements (SLAs) to be defined 
between customers and network service providers with respect to QoS 
requirements. The service provider then needs to ensure that the 
requirements are recognized and receive appropriate treatment across 
network layers. 


Work is in progress to specify methods for combining local values of 
performance metrics to estimate the performance of the complete path. 
See Section 8 of [Y.1541], [RFC5835], and [COMPOSITION]. 
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2.2. Y.1541-QOSM Processing Requirements 


[TRQ-QoS-SIG] guides the specification of signaling information for 
IP-based QoS at the interface between the user and the network (UNI) 
and across interfaces between different networks (NNI). To meet 
Specific network performance requirements specified for the Y.1541 
QoS classes [Y.1541] , a network needs to provide specific user-plane 
functionality at the UNI and NNI. Dynamic network provisioning at a 
UNI and/or NNI node allows a traffic contract for an IP flow to be 
dynamically requested from a specific source node to one or more 
destination nodes. In response to the request, the network 
determines if resources are available to satisfy the request and 
provision the network. 


For implementations to claim compliance with this memo, it MUST be 
possible to derive the following service-level parameters as part of 
the process of requesting service: 

a. Y.1541 QoS class, 32-bit integer, range: 0-7 

b. rate (r), octets per second 

C. peak rate (p), octets per second 

d. bucket size (b), octets 

e. maximum packet size (MPS), octets, IP header + IP payload 

f. Diffserv PHB class [RFC2475] 

g. admission priority, 32-bit integer, range: 0-2 


Compliant implementations MAY derive the following service-level 
parameters as part of the service request process: 


h. peak bucket size (Bp), octets, 32-bit floating point number in 
single-precision IEEE floating point format [IEEE754] 


i. restoration priority, multiple integer values defined in 
Section 3 below 


All parameters except Bp and restoration priority have already been 
Specified in [RFC5975]. These additional parameters are defined as 


o Bp, the size of the peak-rate bucket in a dual-token bucket 
arrangement, essentially setting the maximum length of bursts in 
the peak-rate stream. For example, see Annex B of [Y.1221] 
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3% 


3 


o restoration priority, as defined in Section 3 of this memo 
Their QSPEC Parameter format is specified in Section 3. 


It MUST be possible to perform the following QoS-NSLP signaling 
functions to meet Y.1541-QOSM requirements: 


a. accumulate delay, delay variation, and loss ratio across the end- 
to-end connection, which may span multiple domains. 


b. enable negotiation of Y.1541 QoS class across domains. 


c. enable negotiation of delay, delay variation, and loss ratio 
across domains. 


These signaling requirements are supported in [RFC5974], and the 
functions are illustrated in Section 4 of this memo. 


Additional QSPEC Parameters for Y.1541 QOSM 


The specifications in this section extend the QSPEC [RFC5975]. 


.1. Traffic Model (TMOD) Extension Parameter 


The traffic model (TMOD) extension parameter is represented by one 
floating point number in single-precision IEEE floating point format 
and one 32-bit reserved field. 


0 1 2 3 
0-1 2 $34 5.6 7 g 9 0-12 3 4550 78.9 01.2.23 4 5.6 78 9 0; 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

[M|E|N|r| 15 Ir [e| ez] 1 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Peak Bucket Size [Bp] (32-bit IEEE floating point number) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


Figure 1: TMOD Extension 


The Peak Bucket Size term, Bp, is represented as an IEEE floating 
point value [IEEE754] in units of octets. The sign bit MUST be zero 


(all values MUST be non-negative). Exponents less than 127 (i.e., 0) 
are prohibited. Exponents greater than 162 (i.e., positive 35) are 
discouraged, except for specifying a peak rate of infinity. Infinity 


is represented with an exponent of all ones (255), and a sign bit and 
mantissa of all zeros. 
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The QSPEC parameter behavior for the TMOD extended parameter follows 
that defined in Section 3.3.1 of [RFC5975]. The new parameter (and 
all traffic-related parameters) are specified independently from the 
Y.1541 class parameter. 


3.2. Restoration Priority Parameter 


Restoration priority is the urgency with which a service requires 
successful restoration under failure conditions. Restoration 
priority is achieved by provisioning sufficient backup capacity, as 
necessary, and allowing relative priority for access to available 
bandwidth when there is contention for restoration bandwidth. 
Restoration priority is defined as follows: 


0 1 2 3 
0123456789 0123456789012345678901 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
[M|E|N|r| 16 |r|r|rlr| 1 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| Rest. Priority| TTR | EOR | (Reserved) | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Figure 2: Restoration Priority Parameter 


This parameter has three fields and a reserved area, as defined 


below. 

Restoration Priority Field (8-bit unsigned integer): 3 priority 
values are listed here in the order of lowest priority to highest 
priority: 


0 - best effort 
1 - normal 
2 - high 


These priority values are described in [Y.2172], where best-effort 
priority is the same as Priority level 3, normal priority is 
Priority level 2, and high priority is Priority level 1. There 
are several ways to elaborate on restoration priority, and the two 
current parameters are described below. 


Time-to-Restore (TTR) Field (4-bit unsigned integer): Total amount 
of time to restore traffic streams belonging to a given 
restoration class impacted by the failure. This time period 


depends on the technology deployed for restoration. A fast 
recovery period of « 200 ms is based on current experience with 
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Synchronous Optical Network (SONET) rings and a slower recovery 
period of 2 seconds is suggested in order to enable a voice call 
to recover without being dropped. Accordingly, TTR restoration 
suggested ranges are: 


0 - Unspecified Time-to-Restore 
1 - Best Time-to-Restore: «- 200 ms 
2 — Normal Time-to-Restore <= 2 s 


Extent of Restoration (EOR) Field (4-bit unsigned integer): 


Percentage of traffic belonging to the restoration class that can 
be restored. This percentage depends on the amount of spare 
capacity engineered. All high-priority restoration traffic, for 
example, may be "guaranteed" at 100$ by the service provider. 
Other classes may offer lesser chances for successful restoration. 
The restoration extent for these lower priority classes depend on 
SLAs developed between the service provider and the customer. 


EOR values are assigned as follows: 
0 - unspecified EOR 


1 - high priority restored at 100%; 
medium priority restored at 100$ 


2 - high priority restored at 100%; 
medium priority restored at 80$ 


3 - high priority restored »- 80$; 
medium priority restored »- 80$ 


4 — high priority restored >= 80%; 
medium priority restored >= 60$ 


5 - high priority restored >= 60%; 
medium priority restored »- 60$ 


Reserved: These 2 octets are reserved. The Reserved bits MAY be 


Ash, 


designated for other uses in the future. Senders conforming to 
this version of the Y.1541 QOSM SHALL set the Reserved bits to 
zero. Receivers conforming to this version of the Y.1541 QOSM 
SHALL ignore the Reserved bits. 
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4. Y.1541-QOSM Considerations and Processing Example 
In this section, we illustrate the operation of the Y.1541 QOSM, and 
show how current QoS-NSLP and QSPEC functionality is used. No new 
processing capabilities are required to enable the Y.1541 QOSM 
(excluding the two OPTIONAL new parameters specified in Section 3). 


4.1. Deployment Considerations 


[TRQ-QoS-SIG] emphasizes the deployment of Y.1541 QNEs at the borders 


of supporting domains. There may be domain configurations where 
interior QNEs are desirable, and the example below addresses this 
possibility. 


4.2. Applicable QSPEC Procedures 


All procedures defined in Section 5.3 of [RFC5975] are applicable to 
this QOSM. 


4.3. QNE Processing Rules 


Section 7 of [TRQ-QoS-SIG] describes the information processing in 
Y.1541 QNEs. 


Section 8 of [Y.1541] defines the accumulation rules for individual 
performance parameters (e.g., delay, jitter). 


When a QoS NSIS initiator (ONI) specifies the Y.1541 QoS Class 
number, «Y.1541 QoS Class», it is a sufficient specification of 
objectives for the «Path Latency», «Path Jitter», and «Path BER» 
parameters. As described in Section 2, some Y.1541 Classes do not 
set objectives for all the performance parameters above. For 
example, Classes 2, 3, and 4 do not specify an objective for «Path 
Jitter> (referred to as IP Packet Delay Variation). In the case that 
the QoS Class leaves a parameter unspecified, then that parameter 
need not be included in the accumulation processing. 


4.4. Processing Example 


As described in the example given in Section 3.4 of [RFC5975] and as 
illustrated in Figure 3, the QoS NSIS initiator (ONI) initiates an 
end-to-end, interdomain QoS NSLP RESERVE message containing the 
Initiator QSPEC. In the case of the Y.1541 QOSM, the Initiator QSPEC 
Specifies the «Y.1541 QOS Class», «TMOD», «TMOD Extension», 
«Admission Priority», «Restoration Priority», and perhaps other QSPEC 
parameters for the flow. As described in Section 3, the TMOD 
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extension parameter contains the OPTIONAL Y.1541-Q0SM-specific terms; 
restoration priority is also an OPTIONAL Y.1541-QOSM-specific 
parameter. 


As Figure 3 below shows, the RESERVE message may cross multiple 
domains supporting different QOSMs. In this illustration, the 
Initiator QSPEC arrives in a QoS NSLP RESERVE message at the ingress 
node of the local-QOSM domain. As described in [RFC5974] and 
[RFC5975], at the ingress edge node of the local-QOSM domain, the 
end-to-end, interdomain QoS-NSLP message may trigger the generation 
of a Local QSPEC, and the Initiator QSPEC is encapsulated within the 
messages signaled through the local domain. The Local QSPEC is used 
for QoS processing in the local-QOSM domain, and the Initiator QSPEC 
is used for QoS processing outside the local domain. As specified in 
[RFC5975], if any QNE cannot meet the requirements designated by the 
Initiator QSPEC to support an optional QSPEC parameter (i.e., with 
the M bit set to zero for the parameter), the QNE sets the N flag 
(not supported flag) for the parameter to one. For example, if the 
QNE cannot support the accumulation of end-to-end delay with the 
«Path Latency» parameter, where the M flag for the «Path Latency> 
parameter is set to zero denoting «Path Latency» as an optional 
parameter, the QNE sets the N flag (not supported flag) for the «Path 
Latency» parameter to one. 


Also, the Y.1541-QOSM requires negotiation of the «Y.1541 QoS Class» 
across domains. This negotiation can be done with the use of the 
existing procedures already defined in [RFC5974]. For example, the 
QNI sets «Desired QoS», «Minimum QoS», and «Available QoS» objects to 
include «Y.1541 QoS Class», which specifies objectives for the «Path 
Latency», «Path Jitter», and «Path BER» parameters. In the case that 
the QoS Class leaves a parameter unspecified, then that parameter 
need not be included in the accumulation processing. The QNE/domain 
SHOULD set the Y.1541 class and cumulative parameters, e.g., «Path 
Latency», that can be achieved in the «QoS Available» object (but not 
less than specified in «Minimum QoS»). This could include, for 
example, setting the «Y.1541 QoS Class» to a lower class than 
specified in «QoS Desired» (but not lower than specified in «Minimum 
QoS»). If the «Available QoS» fails to satisfy one or more of the 
«Minimum QoS» objectives, the QNE/domain notifies the QNI and the 
reservation is aborted. Otherwise, the QoS NSIS Receiver (QNR) 
notifies the QNI of the <QoS Available> for the reservation. 


When the available «Y.1541 QoS Class» must be reduced from the 
desired «Y.1541 QoS Class» (say, because the delay objective has been 
exceeded), then there is an incentive to respond with an available 
value for delay in the «Path Latency> parameter. If the available 
«Path Latency» is 150 ms (still useful for many applications) and the 
desired QoS is Class 0 (with its 100 ms objective), then the response 
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would be that Class 0 cannot be achieved, and Class 1 is available 
(with its 400 ms objective). In addition, this QOSM allows the 
response to include an available «Path Latency» = 150 ms, making 
acceptance of the available «Y.1541 QoS Class» more likely. There 
are many long paths where the propagation delay alone exceeds the 
Y.1541 Class 0 objective, so this feature adds flexibility to commit 
to exceed the Class 1 objective when possible. 


This example illustrates Y.1541-QOSM negotiation of «Y.1541 QoS 
Class» and cumulative parameter values that can be achieved end-to- 
end. The example illustrates how the ONI can use the cumulative 
values collected in «QoS Available» to decide if a lower «Y.1541 QoS 
Class» than specified in «QoS Desired> is acceptable. 


e2e <->] e2e &K------------------------- >| e2e «-»! e2e 
QOSM QOSM QOSM QOSM 
| the perce: NU Wu a | 
| NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP | 
[Y.1541| [local | |local | [local | [local | [Y.1541| 
| QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | 


ONI ONE ONE ONE ONE ONR 
(End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) 


Figure 3: Example of Y.1541-QOSM Operation 
4.5. Bit-Level QSPEC Example 


This is an example where the QOS Desired specification contains the 
TMOD-1 parameters and TMOD extended parameters defined in this 
specification, as well as the Y.1541 Class parameter. The QOS 
Available specification utilizes the Latency, Jitter, and Loss 
parameters to enable accumulation of these parameters for easy 
comparison with the objectives desired for the Y.1541 Class. 


This example assumes that all the parameters MUST be supported by the 
QNES, so all M-flags have been set to 1. 
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0 1 2 3 
0123456789 0123456789012345678901 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Vers.|QType=I|QSPEC Proc.=0/1|0|RIRIR| Length = 23 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
E|r|r|r| Type = 0 (QoS Des.) |r|r|rlr| Length = 10 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
1|E|olr| ID = 1 <TMOD-1> Irlrlrlr| Length = 5 | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


十 
TMOD Rate-1 [r] (32-bit IEEE floating point number) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
TMOD Size-1 [b] (32-bit IEEE floating point number) 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Peak Data Rate-1 [p] (32-bit IEEE floating point number) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Minimum Policed Unit-1 [m] (32-bit unsigned integer) 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Maximum Packet Size [MPS] (32-bit unsigned integer) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
1|E|N]|xr| 15 [Eb epe] 1 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Peak Bucket Size [Bp] (32-bit IEEE floating point number) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
N|r| 14 [se [e 1 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
1 QoS Cis. | (Reserved) 
一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
工 c|=|=| Type = 1 (QoS Avail) [xs e [s e] Length = 11 | 
一 十 一 


十 一 
1|E 
十 一 


Y.1 


(zal 


E EN| 工 | 3 eps | ae | ale 
一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 
Path Latency (32-bit integer) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
1|E|N|z| 4 SES EE 4 | 
一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 
Path Jitter STAT1 (variance) (32-bit integer) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Path Jitter STAT2(99.9$-ile) (32-bit integer) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Path Jitter STAT3(minimum Latency) (32-bit integer) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| 


Path Jitter STAT4 (Reserved) (32-bit integer) 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
1|E|N]|xr| 5 Irlrlrl|r| 1 


一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 一 一 一 十 
Path Packet Loss Ratio (32-bit floating point) | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


十 一 

| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
+ 
| 
十 一 
| 
十 一 
| 
十 一 
| 
十 一 
| 
+ 
| 
十 一 十 一 十 一 十 一 
|i|E|N|x 14 Le Fees] Js 
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十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
|Y.1541 QoS Cis. | (Reserved) 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Figure 4: An Example QSPEC (Initiator) 
where 32-bit floating point numbers are as specified in [IEEE754]. 
4.6. Preemption Behavior 
The default QNI behavior of tearing down a preempted reservation is 
followed in the Y.1541 QOSM. The restoration priority parameter 
described above does not rely on preemption. 
5. IANA Considerations 
This section defines additional codepoint assignments in the QSPEC 
Parameter ID registry and establishes one new registry for the 
Restoration Priority Parameter (and assigns initial values), in 
accordance with BCP 26 [RFC5226]. It also defines the procedural 
requirements to be followed by IANA in allocating new codepoints for 
the new registry. 
5.1. Assignment of QSPEC Parameter IDs 
This document specifies the following QSPEC parameters, which have 
been assigned in the QSPEC Parameter ID registry created in 
[RFC5975]: 
<TMOD Extension> parameter (Section 3.1, ID=15) 
<Restoration Priority> parameter (Section 3.2, ID=16) 


5.2. Restoration Priority Parameter Registry 


The Registry for Restoration Priority contains assignments for 3 
fields in the 4-octet word and a Reserved section of the word. 


This specification creates the following registry with the structure 
as defined below. 


5.2.1. Restoration Priority Field 
The Restoration Priority Field is 8 bits in length. 


The following values are allocated by this specification: 
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0-2: assigned as specified in Section 3.2: 
0: best-effort priority 
1: normal priority 
2: high priority 
Further values are as follows: 
3-255: Unassigned 
The registration procedure is Specification Required. 
5.2.2. Time to Restore Field 
The Time to Restore Field is 4 bits in length. 
The following values are allocated by this specification: 
0-2: assigned as specified in Section 3.2: 
0 - Unspecified Time-to-Restore 
1 - Best Time-to-Restore: <= 200 ms 
2 - Normal Time-to-Restore <= 2 s 
Further values are as follows: 
3-15: Unassigned 
The registration procedure is Specification Required. 
5.2.3. Extent of Restoration Field 
The Extent of Restoration (EOR) Field is 4 bits in length. 
The following values are allocated by this specification: 
0-5: assigned as specified in Section 3.2: 
0 - unspecified EOR 


1 - high priority restored at 100%; 
medium priority restored at 100$ 
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2 - high priority restored at 100%; 
medium priority restored at 80$ 


3 - high priority restored »- 80$; 
medium priority restored »- 80$ 


4 — high priority restored >= 80%; 
medium priority restored »- 60$ 


5 - high priority restored >= 60%; 
medium priority restored »- 60$ 


Further values are as follows: 

6-15: Unassigned 

The registration procedure is Specification Required. 
6. Security Considerations 


The security considerations of [RFC5974] and [RFC5975] apply to this 
document. 


The restoration priority parameter raises possibilities for theft-of- 
service attacks because users could claim an emergency priority for 
their flows without real need, thereby effectively preventing serious 
emergency calls from getting through. Several options exist for 
countering such attacks, for example: 


- only some user groups (e.g., the police) are authorized to set the 
emergency priority bit 


- any user is authorized to employ the emergency priority bit for 
particular destination addresses (e.g., police or fire 


departments) 


There are no other known security considerations based on this 
document. 
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